should we also set the min number of phases to 1?

Sure, unless we can think of a genuinely useful reason to create a no-op CER? I can't think of one though.

Update: Looks like we've intentionally built in the ability to have phases initially unset, and allow the normally immutable list to be updated once. If we want to preserve that, we can't set the minimum length to 1 with omitempty present. Removing omitempty removes our ability to leave it unset. Is it vital that we keep this in place?

While we only use inline objects, it's ok to set a minimum. When we move to sharding, it could be that we'll want to create the ClusterExtensionRevision object first, then create the shards with the ownerref, then update the revision with the shard refs.

Here's the helm chunked secret implementation: https://github.com/operator-framework/helm-operator-plugins/blob/f1e4eaf3b3924d3339dda2eee7f4520c47fd6162/pkg/storage/chunked.go#L62-L90

There we precompute everything, then:

1. Create the immutable index object with all of the chunk references pre-filled
2. Create the immutable chunks with owner refs to the index

We can do the same with the CER right?

1. Make its phases fully immutable
2. Generate the phase object contents and figure out what the names are going to be so we can pre-fill references in the CER
3. Generate the CER with the phase object references pre-filled
4. Generate the phase objects with the CER ownerRef

That way:

1. If we try to read the phases from the CER after 3, but before 4, we correctly get an error instead of incorrectly assuming there are no phases
2. If the CER is deleted between 3 and 4, we'll end up putting an ownerref on the phase objects that for an object that is already deleted and garbage collect will automatically delete the phase objects.
3. Phases are immutable and create-only and we don't have to handle errors that could occur on an attempt to update the phases.

The comment says “The minimum number of inlinePhases is 1”, but phases is still declared +optional and existing tests/validations allow phases to be unset or empty. This doc looks incorrect/misleading; either enforce a minimum (e.g., MinItems=1 when phases is set / required) or update the comment to reflect that zero phases is allowed.

The new XValidation uses format.dns1123Label() which (depending on Kubernetes/CEL semantics) may allow leading digits, while the error message implies an alphabetic first character. If the intent is to require a leading letter (as the previous regex did), consider switching back to a regex-based rule (or OpenAPI pattern) that enforces the leading-letter constraint, or update the message/tests to match the actual accepted values.

CollisionProtection is now required, but the doc still says “When set to "Prevent" (the default)…”. Since the API no longer defaults this field, this wording is misleading—either remove the “(the default)” phrasing or reintroduce explicit defaulting behavior.

CollisionProtection is marked +required, but the JSON tag still includes omitempty. As with LifecycleState, this can lead to marshaled revisions that omit a required field when the zero value is present. Consider removing omitempty to match repo conventions for required fields.

lifecycleState is marked +required but the JSON tag still uses omitempty, which is inconsistent with other required API fields in this repo (e.g. CatalogFilter.PackageName). Consider removing omitempty so clients using typed structs can’t accidentally omit a required field during marshaling.

collisionProtection is now +required, but the field tag is still json:"collisionProtection,omitempty". For required fields elsewhere in the API, the JSON tag typically omits omitempty; consider removing it here to match the required/optional contract and avoid silently dropping an unset value during marshaling.

The schema description for phases[].name says phase names “start and end with an alphanumeric character”, but the CEL validation message says the name must start with an alphabetic character. Please make these consistent to avoid confusing API consumers (either adjust the description or the validation/message).

The schema description for phases[].name says phase names “start and end with an alphanumeric character”, but the CEL validation message says the name must start with an alphabetic character. Please make these consistent to avoid confusing API consumers (either adjust the description or the validation/message).

Test case names refer to inlinePhases, but the API field is spec.phases. Renaming these cases would make failures easier to interpret and keep terminology consistent with the API surface.

The schema description for phases[].name says phase names “start and end with an alphanumeric character”, but the CEL validation message says the name must start with an alphabetic character. Please make these consistent to avoid confusing API consumers (either adjust the description or the validation/message).